scripts/scr_Table/scr_Table.gml (1)

96-99: CRITICAL MALFUNCTION DETECTED: Duplicate ritual invocation.

The hover() subroutine is executed twice when the cursor sanctifies a row, Tech-Priest. Lines 96-99 constitute redundant logic—this code fragment must be purged, as the restructured input handling at lines 100-115 already encompasses this functionality.

Impact: Performance degradation and potential state corruption if hover() possesses side effects.

⚙️ Requisite ablation sequence

 				}
-			}
-			if (_row_entered && struct_exists(_row,"hover")){
-				//show_debug_message($"click : {struct_exists(_row,"click_left")}");
-				_row.hover();
-			}
-			if (_row_entered){
+			}
+			if (_row_entered){
 				if (struct_exists(_row,"hover")){

objects/obj_controller/Draw_0.gml (1)

2-2: Ancient directive persists, Tech-Priest. Query: Shall I inscribe this task into the issue repository?

The TODO annotation indicates unresolved labour—the transference of draw operations to the GUI layer awaits completion.

Wouldst thou desire the creation of a tracking issue for this architectural migration?

scripts/scr_specialist_training/scr_specialist_training.gml (2)

265-265: The sacred refactor pattern has been violated here, Tech-Priest.

Whilst all other role invocations throughout this codex have been migrated to draw from the _roles array, this line still invokes the deprecated obj_ini.role[100,17] pattern. The _roles variable has been prepared at line 258, yet remains unutilised.

🔎 Rectification pattern for the inconsistency

-novice_type = string("{0} Aspirant",obj_ini.role[100,17]);
+novice_type = string("{0} Aspirant",_roles[17]);

---

3-431: The machine spirit observes repeated invocations of active_roles(), Tech-Priest.

This function is summoned six times across the specialist training rituals. Whilst each function's scope demands its own _roles binding, should active_roles() bear computational burden, consider passing _roles as a sacred parameter to the training functions rather than re-invoking the lookup ritual within each.

However, if active_roles() be but a simple array accessor, this pattern remains sound and maintainable.

scripts/scr_unit_quick_find_pane/scr_unit_quick_find_pane.gml (2)

448-448: Ambiguous equality operator, Tech-Priest. Verify the intent of this condition.

The Machine Spirit detects if (hide_sequence=30) — a single = within a conditional expression. In the arcane tongue of GML, this may evaluate as comparison, yet it invites confusion and potential error. If this is intended as equality check, the double sigil == is the sanctioned form for clarity.

🔎 Proposed clarification

-			if (hide_sequence=30) then hide_sequence=0;
+			if (hide_sequence==30) then hide_sequence=0;

---

128-231: The update_mission_log function grows in complexity, Tech-Priest.

The Machine Spirit notes that this function now handles multiple disparate data sources: planetary problems, controller quests, and fleet events. As new event types are added, consider whether extracting helper methods for each source type would preserve clarity and maintainability. The current implementation functions, but future expansion may warrant modularisation.

scripts/scr_struct_functions/scr_struct_functions.gml (1)

5-9: Ancient deprecated ritual awaits purging.

Tech-Priest, this deprecated function-relic bears the mark of deletion yet persists in the codex. The comment-scroll proclaims its obsolescence—it but wraps variable_clone() in vestigial ceremony.

Would you have this Machine Spirit open a sacred tracking-issue in your repository's archives to ensure this expungement is not forgotten? Or shall we proceed to excise it forthwith?

scripts/scr_system_search_helpers/scr_system_search_helpers.gml (1)

186-197: Critical logic corruption detected, Tech-Priest. The data-spirits cry out in anguish.

The conditional at lines 194-196 shall always evaluate true within this block, for _types_sort (which guards entry at line 186) equals array_length(types). Thus, any star marked _add = true by the loop shall be immediately overwritten to false. All stars with type filtering shall be rejected. This is a grievous malfunction.

🔧 Proposed litany of correction

 			if (_add && _types_sort){
 				_add = false;
 				for (var i=1;i<=planets;i++){
 					if (array_contains(types,p_type[i])){
 						_add = true;
 						break;
 					}
 				}
-				if (array_length(types)){
-					_add = false;
-				}				
 			}

objects/obj_controller/Alarm_6.gml (3)

52-59: CRITICAL HERESY DETECTED — Assignment operator corrupts conditional logic, Tech-Priest.

The Machine Spirit perceives a most grievous error. The single = operator performs assignment, not comparison. This heretical construct shall:

1. Overwrite man[f] with "vehicle" for every iteration
2. Overwrite ma_role[f] with each vehicle type string
3. Corrupt the sacred data arrays and produce erroneous vehicle counts

In GML, equality comparison requires == or = only within if parentheses when intended as comparison — but the current syntax is ambiguous and dangerous.

🔧 Proposed sanctification of the code-runes

             // sets up count for the vehicles
             // TODO This needs to be extended to accomodate the selection text like the man ones
-            if (man[f]="vehicle"){
+            if (man[f]=="vehicle"){
                 vanz+=1;
-                if (ma_role[f]="Land Raider") then lrad+=1;
-                if (ma_role[f]="Rhino") then rhi+=1;
-                if (ma_role[f]="Predator") then pre+=1;
-                if (ma_role[f]="Land Speeder") then lspi+=1;
-                if (ma_role[f]="Whirlwind") then whi+=1;
+                if (ma_role[f]=="Land Raider") then lrad+=1;
+                if (ma_role[f]=="Rhino") then rhi+=1;
+                if (ma_role[f]=="Predator") then pre+=1;
+                if (ma_role[f]=="Land Speeder") then lspi+=1;
+                if (ma_role[f]=="Whirlwind") then whi+=1;
             }

---

85-89: Inconsistent data source for Librarian role designation, Tech-Priest.

The Machine Spirit observes that this block still invokes obj_ini.role[100,17] directly, whilst all other role references utilise the cached _roles array. This inconsistency violates the sanctified refactor pattern.

🔧 Proposed harmonisation

     if (lib>0){
-        selecting_dudes+=string(lib)+" "+string(obj_ini.role[100,17]);
+        selecting_dudes+=string(lib)+" "+string(_roles[17]);
         if (lib>1) then selecting_dudes+="s";
         selecting_dudes+=", ";
     }

---

214-214: CRITICAL HERESY — Assignment operator in conditional, Tech-Priest.

The Machine Spirit detects assignment (=) where comparison (==) is required. This construct shall:

1. Assign -1 to sel_promoting
2. Evaluate as truthy (non-zero)
3. Then immediately overwrite with 0

The result: sel_promoting is always set to 0 at this juncture, regardless of its prior state.

🔧 Proposed sanctification

-    if (sel_promoting=-1) then sel_promoting=0;
+    if (sel_promoting==-1) then sel_promoting=0;

scripts/scr_event_code/scr_event_code.gml (1)

351-354: Inconsistent error pathway: exit versus return false.

Tech-Priest, the default case still uses exit whilst line 323 uses return false. This inconsistency violates the principle of uniform behaviour. The function should return false in all error paths.

🔎 Proposed harmonisation

 		default:
 			log_error("RE: Enemy, no faction could be chosen");
-			exit;
+			return false;

scripts/scr_buttons/scr_buttons.gml (1)

456-456: Unreachable code detected after return statement, Tech-Priest.

The pop_draw_return_values() invocation on line 456 exists beyond the conditional return statements (lines 451 and 454). This code shall never execute, leaving the draw state stack potentially corrupted.

🔎 Excision of dead code

         } else {
             pop_draw_return_values();
             return false;
         }
-        pop_draw_return_values();
     };

scripts/scr_marine_struct/scr_marine_struct.gml (1)

2013-2031: Critical logic corruption detected in name_role function, Tech-Priest.

The machine spirit perceives conflicting directives:

1. Line 2024: The string "{temp_role} {name()}" lacks the sacred $ prefix for template interpolation. This shall produce literal text rather than variable substitution.

2. Line 2030: The return statement invokes string("{0} {1}", temp_role, name()), discarding the _name variable constructed with epithet data (lines 2024-2029). The epithet logic is rendered vestigial.

🔎 Corrected logic pathway

     static name_role = function(include_epithet = true) {
         var temp_role = role();
         if (squad != "none") {
             if (struct_exists(obj_ini.squad_types[$ obj_ini.squads[squad].type], temp_role)) {
                 var role_info = obj_ini.squad_types[$ obj_ini.squads[squad].type][$ temp_role];
                 if (struct_exists(role_info, "role")) {
                     temp_role = role_info[$ "role"];
                 }
             }
         }

-        var _name = "{temp_role} {name()}";
+        var _name = $"{temp_role} {name()}";
         if (include_epithet){
             if (array_length(epithets)){
                 _name += $" {epithets[0].title}";
             }
         }
-        return string("{0} {1}", temp_role, name());
+        return _name;
     };

objects/obj_en_fleet/Alarm_1.gml (1)

10-10: Observation: TODO marker detected, Tech-Priest.

This cogitator observes a TODO directive regarding the centralisation of orbiting logic. Dost thou wish this unit to generate an issue within the sacred archives of GitHub to track this pending rite of code refinement?

scripts/scr_enemy_ai_d/scr_enemy_ai_d.gml (1)

449-458: CRITICAL MALFUNCTION DETECTED, TECH-PRIEST!

The machine spirit perceives a grievous error in the loop construct. The variable planet is declared with value 1, yet the loop condition i<=planets and increment i++ operate upon i - a variable from a prior loop scope. Furthermore, planet never receives increment, causing system_garrison[planet] to eternally reference index 1.

This shall cause incorrect garrison processing and potentially undefined behaviour when i exceeds planets.

🔎 Proposed corrective rite

 	// Local problems will go here
 	var planet;
-	for (var planet=1;i<=planets;i++){
+	for (var planet=1;planet<=planets;planet++){
 		if (i < array_length(system_garrison)){
-			var garrison = system_garrison[planet];
+			var garrison = system_garrison[planet];
 			if (garrison.garrison_force){
 				if (garrison.garrison_disposition_change(self,planet)!="none"){
 					dispo[planet]+=garrison.dispo_change;
 				}
 			}
 		}
 	}

Additionally, line 450 should use planet instead of i for the bounds check:

-		if (i < array_length(system_garrison)){
+		if (planet < array_length(system_garrison)){

scripts/scr_enemy_ai_a/scr_enemy_ai_a.gml (1)

248-263: default_imperium_attack ternary is dense; consider making the intent more explicit

Tech-Priest, this line encodes a non‑trivial doctrinal rule in a compact ternary:

default_imperium_attack = guard_score>0 && !((guard_score<=0.5) && (pdf_score>0)) ?"guard":"pdf";

While correct, the nested condition and inline ternary are not immediately self‑evident to lesser adepts.

Would it aid future maintenance to extract the predicate into a named boolean, e.g. var guard_preferred = ...; followed by a simpler if/else, so the choice between Guard and PDF becomes narratively clear in the code rather than encoded as a riddle?

scripts/scr_enemy_ai_b/scr_enemy_ai_b.gml (1)

95-107: String interpolation and Low Gothic corruption detected

Tech-Priest, the alert incantation at line 96 manifests two grievances:

• The string "Planet {planet_numeral_name(i)} ..." lacketh the $ prefix, rendering {planet_numeral_name(i)} as inert runes rather than executable function call.
• The phrase "has succeed ed" deviates from proper Gothic syntax; the correct declension is "seceded".

Refactor to:

scr_alert("red", "owner", $"Planet {planet_numeral_name(i)} has seceded to the Tau Empire!", x, y);

objects/obj_star/Create_0.gml (1)

64-76: Rectify the GovernorProfile array indexing to align with the 1-based planetary schema

Tech-Priest, the initialisation of p_governor deviates catastrophically from the established pattern. The array is first created with _planet_array_size entries, then obliterated and rebuilt with array_push, yielding indices 0..6 (seven entries). Yet the rest of thy codebase accesses planets via 1-based indexing—when code invokes p_governor[planet] with planet ∈ [1..8], it encounters a void at index 8, and the logic collapses into undefined darkness.

All sibling arrays (p_operatives, p_features, etc.) maintain the proper shape: nine slots indexed 0..8, with indices 1..8 bearing data. Restore p_governor to this sanctified form:

- p_governor = array_create(_planet_array_size, "");
+ p_governor = array_create(_planet_array_size);

- p_governor = [];
-
-for (var i=1;i<8;i++){
-    array_push(p_governor, new GovernorProfile());
-}
+for (var i = 1; i < _planet_array_size; i++){
+    p_governor[i] = new GovernorProfile();
+}

This ensures every planetary slot 1..8 receives its GovernorProfile and prevents undefined memory access.

scripts/scr_random_event/scr_random_event.gml (1)

644-679: Unreachable code detected, Tech-Priest.

The cogitator's logic-pathways reveal a discrepancy most grave. Cases 10 (Heretics) and 13 (Necron) at lines 666-675 shall never execute, for the enemy selection at line 646 invokes only choose(7,8,9). These xenos and heretical spawn remain forever dormant in the code-scriptures.

Was this deliberate pruning of the enemy roster, or does the Machine Spirit sense an incomplete implementation?

scripts/scr_mission_functions/scr_mission_functions.gml (1)

990-1008: Critical logic error in add_new_problem function.

Tech-Priest, a most grievous corruption exists at line 994. The condition p_problem[planet][i] == timer should be p_problem[planet][i] == "" to find an empty slot. Currently, this seeks a slot containing the timer value, which will virtually never match, causing problems to never be added.

🔎 Urgent correction required

 	if (star=="none"){
 		for (var i=0;i<array_length(p_problem[planet]);i++){
-			if (p_problem[planet][i] == timer){
+			if (p_problem[planet][i] == ""){
 				p_problem[planet][i]= problem;
 				p_problem_other_data[planet][i]=other_data;
 				p_timer[planet][i] = timer;

scripts/scr_PlanetData/scr_PlanetData.gml (2)

557-563: Refactor: Sanctify this logic within a proper ritual, Tech-Priest.

The machine spirit detects orphaned code-canticles within the constructor corpus. This population-zero reset logic dwells outside method boundaries, executing with each instantiation. Consider relocating this doctrine into refresh_data or a dedicated static purification method.

⚙️ Proposed restructuring

Move this logic into a static method:

+    static purge_empty_planet_corruption = function(){
+        if (population == 0) {
+            system.p_heresy[planet] = 0;
+            system.p_heresy_secret[planet] = 0;
+            for (var i = 0; i < array_length(system.p_influence[planet]); ++i) {
+                system.p_influence[planet][i] = 0;
+            }
+        }
+    }

Then invoke within refresh_data or at the conclusion of population mutations.

---

324-554: Consider decomposition of complex ork growth ritual, Tech-Priest.

The grow_ork_forces incantation spans 230 lines with multiple nested conditionals and repeated reassignment of the _rando designation. The machine spirit suggests partitioning this ceremony into smaller sub-rituals:

• Ork population growth calculation
• Ork spreading mechanics
• Stronghold and Warboss evolution
• Fleet construction logic
• Waaagh departure sequence

This shall enhance clarity and ease future maintenance of the greenskin propagation algorithms.